DR / Availability Diagram
Service availability, primary operating stack, resilience posture, recovery dependencies, and restoration priorities for the CMS platform
🛡️
Users / Service Availability Expectations
HIGH-AVAILABILITY ENTRY PATH
USER
End Users
Access CMS through resilient edge and protected application entry points
AK
Akamai
Highly available edge protection and internet-facing routing layer
AG
Application Gateway
Controlled ingress to protected application endpoints
ING
Ingress Availability
Requests should keep flowing even if downstream components require restart or failover handling
The platform is designed so that the public entry path remains resilient while internal application components can be restored in a controlled order.
PRIMARY APPLICATION RUNTIME
Stateless application services are easier to recover, redeploy, and scale than tightly coupled stateful runtime components
SPA
React SPA
Presentation layer artifact that can be redeployed independently from backend service runtime
BFF
BFF / Orchestration
Stateless API orchestration layer that can be restarted or scaled without preserving internal application state
DOM
Domain Services
Business services are application runtime components that recover primarily through redeployment and restored connectivity
SHR
Shared Platform Services
Workflow, notification, and document services depend on operational stores but remain application-runtime recoverable
Persistent data and storage services define recovery dependency order because application services depend on them for meaningful restoration.
PERSISTENT PLATFORM DEPENDENCIES
FAB
Microsoft Fabric
Read-only enterprise analytical dependency required for data-driven views, summaries, and insight-based screens
DDB
Azure DocumentDB
Operational application store that must be available for workflow state, notifications, preferences, and metadata recovery
ADLS
ADLS Gen2
Persistent object storage for files, attachments, exports, and generated artifacts that must remain recoverable
RECOVERY PRIORITY GROUPS
P1
Priority 1
Edge entry, ingress, and identity path required to re-establish secure access
P2
Priority 2
Operational data stores and file stores required for stateful CMS function recovery
P3
Priority 3
BFF and application services restored once core dependencies are available
P4
Priority 4
Non-blocking supporting integrations, observability enrichment, and outbound delivery channels
Monitoring, alerting, and support services help detect degradation early and guide restoration sequencing during incidents.
RESILIENCE, MONITORING & SUPPORTING SERVICES
AAD
Azure AD
Identity dependency required for authenticated user recovery and secure access restoration
DD
Datadog
Health monitoring, alerting, telemetry, and incident visibility across application and platform paths
IB
Infobip
Outbound delivery integration that is useful but typically not first in recovery order
OPS
Operational Runbooks
Recovery procedures, incident actions, and restoration order guidance for operations teams
DR / AVAILABILITY DESIGN PRINCIPLES
1
Stateless First
Application services should be restartable and redeployable without carrying critical business state in memory
2
Protect Stateful Dependencies
DocumentDB, ADLS, and analytics dependencies determine real functional recovery readiness
3
Restore in Order
Access path, identity, storage, application runtime, then supporting integrations
4
Observe Everything
Availability posture depends on continuous monitoring, alerting, and incident traceability
High-availability entry path
Primary application runtime
Persistent platform dependencies
Recovery priority groups
Resilience & support services
DR / availability principles